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Remarks 



The paragraphs of the Office action are responded to through the corresponding 
numbered paragraphs below. The applicant has addressed each issue in turn and, for 
clarity, has provided a heading for each issue. 



1 . The Examiner objected to claims 22-27 because of informalities. The applicant 
has requested that claims 22-27 be cancelled. The applicant believes that the 
cancellation of these claims makes this objection moot. The applicant believes that this 
response is fully responsive to the objection of this paragraph. The applicant 
respectfully requests reconsideration and withdrawal of this objection. 



2. The Examiner provided the citation to 35 U.S.C. § 1 02 "that form the basis for 
the rejections under this section made in this Office action." The applicant believes that 
no specific response is required for this paragraph. 

3. The Examiner rejected claims "1 and 17-40 under 35 U.S.C. § 102(e), as being 
anticipated by Moura et al." The applicant has requested that claims 1 and 1 7-40 be 
cancelled. The applicant believes that the cancellation of these claims makes this 
objection moot. The applicant believes that this response is fully responsive to the 
objection of this paragraph. The applicant respectfully requests reconsideration and 
withdrawal of this objection. 



4. The Examiner provided the citation to 35 U.S.C. § 1 03(a) "which forms the basis 
for all obviousness rejections set forth in this Office action." The applicant believes that 
no specific response is required for this paragraph. 

The Examiner also reminded the applicant of the applicant's obligation to point 
out the inventor and invention dates of each claim that was not commonly owned at the 
time a later invention was made. The applicant believes all claims are and were 
commonly owned by assignment to Helius, Inc. 

5. The Examiner rejected claims "2-1 6 under 35 U.S.C. § 1 03(a) as being 
unpatentable over Moura et al." The applicant has requested that claims 2-1 6 be 
cancelled. The applicant believes that the cancellation of these claims makes this 
objection moot. The applicant believes that this response is fully responsive to the 
objection of this paragraph. The applicant respectfully requests reconsideration and 
withdrawal of this objection. 



Claim Objections 



Claim Rejections - 35 (JSC §102 



Claim Rejections - 35 USC § 103 
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Conclusion 

6. The Examiner noted that certain "prior art" is made of record and not relied upon 
is considered pertinent to the applicant's disclosure. The applicant appreciates the 
Examiner's search and respectfully requests that this "prior art" be listed among the 
cited references in this case upon allowance. 

7. The Examiner indicated that a shortened statutory period for response has been 
set and that extensions of time may be obtained under the provisions of 37 CFR § 
1.136(a). The applicant is responding within the permitted extension period. 

8. The Examiner provided information concerning communication on this 
application. The applicant appreciates the Examiner's willingness to communicate and 
assist on this case. 

The applicant has requested that claims 1 - 40 be cancelled without prejudice 
and that new claims 41-131 be added. Applicant believes that all issues and points of 
the Examiner's Office action have been addressed. Applicant believes that claims 41- 
131 are patentable over all known prior art. Applicant respectfully requests 
reconsideration and allowance of this application. 

Respectfully submitted this 5th day of May, 2003. 




Lloyd W. Sadler, Reg. No. 40,1 54 
PARSONS BEHLE & LATIMER 
201 South Main Street, Suite 1800 



Salt Lake City, Utah 84111 
Telephone: (801) 532-1234 
Facsimile: (801) 536-61 1 1 
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^traq^ /VERSION WITH MARKINGS TO SHOW CHANGES MADE 

2 Si>ftwiVi^-ArRn^H4t-x t This s pecification m 

3 in cl u d es the computer source code of one preferred embodiment of the invention. In other 

4 emb odiments of th e i n v enti o n , th e i n v enti ve concept may be implem en t ed in other c o mpete? 

5 e ode> in dedicated electronic hardware, in a combination of these, or otherwise. This software 

6 appeedi-x4^her e by^ application in it s entirety and is to be considere d-to-be 

7 part; of the disclosure of this specification. 

RECEIVED 

MAY 0 .9 2003 

9 I. BACKGROUND OF THE INVENTION n , nn 

Te*w>>ogy Center 2100 

10 A. Field of the Inventio»Related Applications. 

1 1 This appl ication is a Continuation of United States Patent Application Serial Number 

12 09/746.438, filed December 20, 2000, which is a Continuation of United States Patent 

13 Application Serial Number 08/943,544. now United States Patent Number 6,205,473 B 1 , filed 

14 October 3, 1997. 

15 B. Reference to Microfiche Appendix. A microfiche appendix, containing three 

16 microfiche and 150 total frames is filed herewith. The microfiche appendix includes the 

1 7 c o m puter source code of one preferred embodiment of the invention. 

18 C. Field of the Invention. 

1 9 This invention relates to methods and systems for communications between computers 

20 and other digital information devices. More particularly, this invention relates to 

21 communications between computers making use of digital satellite communications channels and 

22 computer local area networks, to provide access to the linternet, to facilitate data and software 
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1 distribution, and/or to enhance the capabilities of intranet systems for computers with 

2 connections to local area networks. 

3 Bl). Description of Related Art 

4 It is well established that computers can communicate across local or wide area networks. 

5 It is also well known that satellite receivers and transmitters can be used to transfer high volumes 

6 of digital data. Some efforts have been made to provide communication systems which can be 

7 used to transfer data between computer processors using a variety of communication mediums 

8 (see Moura et al., U.S. Patent No. 5,586,121). However, it is desirable to provide a high-speed, 

9 low-cost, satellite-based communication system which is designed to optimize the use of digital 

1 0 satellite systems for local area networks (LANs). Optimizing the use of the digital satellite 

1 1 channel is best accomplished through the use of asymmetrical communications between the 

1 2 computer server and the int e r ne t lnternet: as opposed to symmetric communication, in which 

1 3 substantially the same data rates and the same media are used for both the transmit direction and 

1 4 the receive direction, and as opposed to communication systems which employ asymmetrical 

1 5 communication between the local area network and the server. Particularly, asymmetrical 

1 6 systems whieh-require upstream router hardware, "backbone" network hardware, or dial-up 

1 7 (internet service providers (ISPs) to create a "hybrid" asymmetrical local system with a 

1 8 symmetrical local area network. Since calls to the internet lnternet can efficiently be made at 

19 relatively low speeds, and since using digital satellites as a communication medium provides the 

20 capability of very high speed responses from the internet! nternet, an asymmetric transmission 

21 from the krtemet lnternet across the digital satellite to the LAN server provides the greatest 

22 system efficiency. 
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1 The most common method of sending and receiving computer information today is a land 

2 line service (i.e., a switched service, a dedicated line, and/or an analog modem, each using 

3 telephone wire lines). However, such a system encounters many problems, including slow 

4 transmission speeds, high access costs, lack of available wire lines, and internet lnternet 

5 congestion. 

6 Satellite communication receivers are commonly used to create or supplement existing 

7 private wide area data and video networks. When used as an extension to a data network, these 

8 satellite links may interconnect local area networks. Satellite links can provide many advantages 

9 over land line service, including potentially high speed data transmission and wide availability. 

1 0 However, typical satellite links have required expensive hardware both to transmit and to receive 

1 1 data. The expense of the hardware has made the use of satellite communication channels 

1 2 generally unavailable to those who most need it. 

1 3 This invention addresses these issues by providing a method and system for providing the 

14 advantages of satellite communications for high volume download data packets and typically 

1 5 using a relatively low speed land line for the low volume upload data request packets. By 

1 6 capitalizing on the asymmetrical nature of internet lnternet dataflow, this invention provides an 

1 7 efficient solution for LAN to satellite intern e t lnternet communications. 

1 8 For general background material the reader is directed to U.S. Patent Nos. 5,095,480, 

19 5,379,296, 5,423,002, 5,488,412, 5,534,913, 5,539,736, 5,541,911, 5,541,927, 5,555,244, 

20 5,583,997, 5,586,121, 5,594,872, 5,610,910, 5,610,920, 5,631,907, 5,659^692, 5,668,857, 

21 5,673,265, each of which is hereby incorporated by reference in its entirety for the material 

22 disclosed therein. 

23 II. SUMMARY OF THE INVENTION 
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1 This invention is a method and system for efficiently communicating between networked 

2 computers using a high speed satellite communications channel. It is an object of this invention 

3 to provide a high speed satellite based information delivery system for local area network 

4 connectivity to the internet lnternet for file, data, software, and/or multimedia distribution. 

5 It is a further object of this invention to provide a data transmission system particularly 

6 well suited to remote location and/or locations where access to high speed data mediums is 

7 unavailable or prohibitively expensive. 

8 It is a further object of this invention to provide a high speed data transmission system 

9 that utilizes a highly flexible and adaptable software method. 

10 It is a further object of this invention to provide a high speed data transmission system 

1 1 that communicates with the i-ntemetlnternet while being inter n et lnternet service provider (ISP) 

12 independent. 

1 3 It is a further object of this invention to provide a high speed data transmission system 

14 that makes use of digital satellite communications technology to enhance data bandwidth, 

1 5 channel reliability, and accessiability. 

16 It is a further object of this invention to provide a high speed data transmission system 

1 7 that utilizes a software method capable of operating on a wide range of server operating systems, 

1 8 including Windows 95, Windows NT, NetWare, Linus, Macintosh, present and future versions 

1 9 and the equivalents. 

20 It is a still further object of this invention to provide a high speed data transmission 

21 system that is compatible with a wide range of communication protocols and/or mediums, 

22 including ISDN, Tl , modem, dedicated phone line, switched phone line, frame relay and ATM. 
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1 It is another object of this invention to provide a method for permitting many client 

2 computer systems, which may be operating system independent and operating on one or more 

3 local area networks, to communicate over a single satellite dish, at very high data rates. 

4 It is a further object of this invention to provide a method using software which can 

5 operate on a wide variety of hardware, operating system, and software platforms, including, but 

6 not limited to: Macintosh, Linux, Unix, OS/2, and Windows NT. 

7 These and other objects of this invention are readily apparent to individuals of ordinary 

8 skill in the art upon further study of the drawings, detailed description, claims and abstract that 

9 are included in this patent disclosure. 

1 0 III. BRIEF DESCRIPTION OF THE DRAWINGS 

1 1 Figure 1 depicts a top level rendering of the major component parts of the communication 

1 2 system invention. 

1 3 Figure 2 depicts a preferred embodiment of the architecture of the invention. 

14 Figure 3 depicts the preferred flow of data through the several protocol transitions in a 

1 5 preferred embodiment of the invention. 

1 6 Figure 4 depicts a top level flow diagram showing the primary steps of the process flow 

1 7 for an example single received data packet in the preferred method of the invention. 

1 8 Figure 5 depicts a detailed flow diagram showing the package delivery major step of the 

1 9 preferred embodiment of the invention. 

20 Figure 6 depicts a detailed flow diagram showing the internet lnternet protocol (IP) major 

21 step of the preferred embodiment of the invention. 

22 Figure 7 depicts a top level flow diagram showing the primary steps of the process flow 

23 for an example transmission of internet Internet protocol datagrams. 
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1 Figure 8 depicts additional detail showing the transfer queue (TxQ) thread processing of 

2 the filter queue step of the transmission portion of the invention. 

3 Figure 9 depicts additional detail showing new queue (NewQ) thread processing of the 

4 filter queue step of the transmission portion of the invention. 

5 Figure 1 0 provides an example embodiment of the user interface of the invention. 

6 IV. DETAILED DESCRIPTION OF THE INVENTION 

7 This invention is a system and method for asymmetric communications? between a 

8 remote information provider and a client computer system residing on a local area network 

9 (LAN), using high bandwidth digital satellite communication channels. The preferred 

10 embodiment of the method of the invention is performed in software residing on a local 

1 1 computer system. The current preferred embodiment of the method software m-is_written in Intel 

1 2 386 assembly code, C and C++ computer languages. The reader is directed to the appended 

1 3 computer software microfiche appendix for a complete disclosure of the software making up the 

14 current best mode of the method of this invention. Alternatively, those of ordinary skill in the art 

1 5 could practice this method in a wide variety of procedures, computer languages, or even in 

16 dedicated electronic hardware. Therefore this patent should not be read to be limited to the 

17 specific embodiment of the provided software microfiche appendix. Rather, this software source 

1 8 code is provided to fully describe one preferred embodiment of the method of this invention. 

19 Also, in its preferred embodiment, this invention performs in association with DirectPC satellite 

20 receivers, Novell NetWare network software, and standard off-the-shelf computer hardware. 

21 Other alternative satellite receiver systems, networking software and computer hardware could 

22 easily be substituted by those of ordinary skill in the art without departing from the essence of 

23 this invention. Similarly, the preferred embodiment, described in the following detailed 
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1 description, includes a number of components and method steps which may not be absolutely 

2 necessary in other embodiments of the invention. The reader is, therefore, directed to the claims 

3 for a description of the range of this patent. 

4 Figure 1 depicts a top level rendering of the major components and communication paths 

5 constituting the system 100 of this invention. A client computer lOla-g is shown clustered with 

6 other client computers on a local area network (LAN) 102. The client computer 101 uses 

7 standard off-the-shelf commercially available software, while the server provides the user 

8 interface to the desired information. The LAN 102 provides the means for communicating from 

9 the client computer 101 to a server 103, which provides the communication interface outside the 

10 LAN. The server 103 receives data from a digital satellite receiver 110, depicted here as a 

1 1 satellite dish, across a signal antenna waveguide 115. The digital satellite receiver 1 10 receives 

1 2 the digital information from a downlink channel 111, which is transmitted from a 

1 3 geosynchronous satellite 1 12. The satellite 1 12 receives the information from a network 

1 4 operations center 1 14 via an uplink channel 1 13. The server 1 03 generally uses the above 

1 5 described communications channel from the network operations center 1 14 for downloads of 

1 6 information, such as i n tern et Internet web page data, software updates, data file distributions and 

1 7 other similar data packages. Alternatively and in addition, this invention provides the capability 

1 8 of using another satellite communication channel to send requests from the client computer 101 

1 9 to the network operations center 1 14. This is a particularly useful feature for access from remote 

20 locations. Use of the satellite communication channel provides important benefits to the 

21 information requestor at the client computer 101, including very high speed data transfer, the 

22 ability to receive broadcast software distributions which in turn means the requestor is likely to 

23 receive such distributions in a more timely and cost effective manner, and the ability to have 
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1 Hito-ftet Internet access from locations where wired communications channels, such as telephone 

2 lines, are either unavailable, overly burdened, or prohibitively expensive. 

3 Figure 1 also shows the preferred, and more typical request communications channel. In 

4 this preferred request channel the client computer 101, connected through the LAN 1 02, through 

5 the server 103, sends a request via modem 105, which typically is connected to the server via a 

6 standard serial RS-232 cable 104. The modem 105 in turn is connected to standard telephone 

7 land lines 107 via a standard phone cable 106. The request is passed across the land lines 107 to 

8 the internet ] ntcrnct service provider 108, which communicates to the internet ! nter.net 109. 

9 This invention is designed to be highly flexible and adaptable to different client computer 

10 101 configurations, both hardware and software as well as with and to a wide variety of 

1 1 communication interfaces. Computer hardware such as personal computers, workstations, mini 

12 computers, mainframe computers and special purpose computational equipment can be 

13 functional client computers 101 as intended within this patent specification. Similarly, computer 

1 4 system operating systems which are supported and used in the preferred and alternative 

1 5 embodiments of this invention included but are not limited to: Windows 3.1, Windows 95, 

16 Windows NT, Macintosh, Linux, Unix, OS/2, NetWare, their current versions, past versions, and 

17 equivalent future versions and the equivalent. Communications interfaces that are or can 

1 8 alternatively be used with or as a part of this invention include routers, ethernet, ISDN 

19 equipment, switched 56, Tl, Token Ring, frame relay, modems, satellite and the equivalent. 

20 The advantage of this preferred mode of operation is that the communication channels are 

21 used in the most efficient manner. Typically, request packets are relatively small and can be 

22 transferred with minimal impact across land lines. While downloaded packets can be very large 

23 with significant amounts of highly concentrated graphics. For the vast majority of client 
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1 computer 1 01 users the limitation of the [ internet or the ability to receive other downloaded file 

2 information is the time it takes for the download transfer to be accomplished. This problem is 

3 solved by transferring the potentially very large downloaded packets (files, graphics, and other 

4 information) using the high bandwidth satellite channel. 

5 Figure 2 depicts a preferred embodiment of the software architecture of the invention. As 

6 shown, in its preferred embodiment, this software operates in association with several standard 

7 commercially available software packages and protocols, including Novell NetWare, Ethernet, 

8 Token Ring, TCP/IP, IPX and AIO. This software method of the invention also makes use of 

9 certain commercially available hardware components, as shown in figure 2, including: the 

10 satellite receiver 1 10, a network router 205 and a modem 104. The reader should understand that 

1 1 this figure 2 presents a single simplified embodiment of the invention. Alternative embodiments 

1 2 could use alternative software packages and protocols, as well as different or multiple hardware 

1 3 components. Figure 2 also shows a single embodiment of the path of information through the 

14 various software and hardware components. Download information packets are received by the 

1 5 satellite receiver 1 1 0, which in turn communicates electronically with the DPC LAN 210, a 

1 6 commercially available hardware driver. The information next passes through the LSL NLM 

1 7 202, a routine commercially provided by Novell Incorporated which acts as an intermediary 

1 8 between the driver and the protocol stack to control information packet transfer. Next, the 

19 TCP/IP 203 protocol stack receives the information packet. The TCP/IP 203 protocol stack is 

20 capable of communicating alternatively with a modem 104, via the LSL NLM 202; the 

21 DPC AGENT 207 routine, core to this invention; the AIO 208, a Novell product for managing 

22 serial communications; and through the AIOCOMX 209, which is the asynchronous 

23 input/output interface to the client computer hardware communication ports, or with router 205, 
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1 via the LSL NLM 202, the DPCAGENT 207, the LSL NLM 202 and an ethernet driver 204. 

2 Alternative embodiments of this invention may make use of other standard commercially 

3 available communication protocols, drivers, hardware and software. 

4 Figure 3 depicts the flow of information in the preferred embodiment of the invention 

5 from the satellite 1 12 to the client computer 101 as well as the flow of information back to the 

6 im eniet lntemet 109 from the client computer 101. Data is received 301 from the satellite 112 by 

7 the satellite receiver 10. Next, the data is transmitted to and received by the server 103 hardware 

8 302 where it is placed in on-board memory. The DPC.LAN DirecPC network card driver 

9 retrieves the data packet from hardware memory 303. Next, if the packet is identified as an 

1 0 i nternet ! nternet protocol (EP) format packet it is delivered to the IP protocol stack 304. If the 

1 1 packet is identified as a transmission control protocol (TCP) segment, it is delivered to the TCP 

12 protocol stack 305. TCP delivers the data packet to a proxy gateway 306. The proxy gateway 

1 3 forwards the data packet to the client computer via the local area network and standard LAN 

14 protocol controllers 307. Next, the client computer processes the data and generates a return 

1 5 packet 308. The return packet is delivered to the proxy gateway via the Ipcal area network and 

16 the standard LAN protocol controllers 309. The return packet is forwarded to the TCP stack 310, 

1 7 and next to the IP stack 311. The IP delivers the return packet to the DPCAGENT.NLM process 

18 312, which delivers the return packet data to a transmit device, such as a modem or a router 313. 

1 9 Figure 4 depicts a top level flow chart rendering of the major steps of the process flow for 

20 a single downloaded data packet section of the invention. Initially the downloaded packet is 

21 received 41 0 by the DirecPC circuit card. This circuit card next transfers the packet data to the 

22 DPC.LAN routine 402. In the preferred embodiment of the invention, as shown in the source 

23 code appendix, the DPC.LAN routine is denoted as DriverlSR proc. This process includes the 
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1 steps of setting up the RAM adapters and establishing a timestamp for the packet. Further 

2 detailed information on the functioning of this routine is found within the software microfiche 

3 appendix. Next, a test is made 403 as to whether the received data is a package delivery or an 

4 wtoH^ .lntcrnct delivery. If the received data is package data, it is delivered 404. Package data 

5 delivery includes and provides the capabilities of simultaneously broadcasting software upgrades 

6 or data files to many client computers, potentially throughout any one continent. Client 

7 computers can also request the package data delivery service to retrieve a package of information 

8 through the client accessible interface of the invention. If the received data is internet lnternet 

9 data, then mtemet lnternet data delivery is made 405. Additional detail on steps 404 and 405 

10 follows in this specification. 

1 1 Figure 5 depicts a detailed flow chart of the preferred embodiment of the package 

1 2 delivery major step of the method of the invention. The data packet is transferred to the 

1 3 DPCAGENT.NLM process 501 . This process is a NetWare Loadable Module (NLM) process 

14 running on NetWare. After the data packet is received 501, a test is made to determine whether 

15 the packet will update the catalog 502. If the catalog will be updated, then it is updated 503 

1 6 using off-the-shelf commercially available software and the process of package delivery for that 

1 7 packet ends 511. If, however, the catalog will not be updated, then a test is performed to 

18 determine whether the site will be updated by the data packet 504. Site updates include 

19 modification of such site parameters as NOC versioning, encryption key updates, and becoming 

20 a member of a group or leaving a group. If the site will be upgraded, then the process performs 

21 the upgrade of the site parameters 505, and the process for this packet ends 511. If the site will 

22 not be updated, then the package file is found and stored on the server disk 506. A test is then 

23 made to determine whether the end-of-file has been encountered 507. If the end-of-file has not 
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1 been encountered then the process for that packet ends 511. However, if the end-of-file has been 

2 encountered, then a test is made to determine whether there are any "holes" in the file, that is 

3 whether the file is incomplete 508. If no holes are found in the file, it is marked as complete 509 

4 and the process for this packet ends 511. If "holes" are found in the file, then a request for 

5 partial retransmit of the missing packet is sent 510, at which point the process for this packet 

6 ends 511. 

7 Figure 6 depicts a detailed flow chart of the preferred embodiment of the krtefflet lnternet 

8 protocol delivery major step of the method of the invention. Internet package delivery OR 

9 Internet Protocol (IP) delivery is a major function of the invention providing the capability of 

1 0 receiving large files from an internet: Internet source at a very high speed. First the data packet is 

1 1 transferred to the DPCAGENT.NLM routine 601 . A test is made to determine whether the data 

12 is in transmission control protocol (TCP) 602. If the data is not in TCP protocol then the data 

1 3 packet is transferred to the Internet Protocol (IP) stack 609 and the process for this data packet 

14 ends 610. If the data is in TCP form then a test is made to determine if a "SYN" or beginning of 

15 section is being initiated 603. If no "SYN" is detected, then a test is made to determine if an end 

16 of session, commonly a FIN or RST command, has been encountered 605. If no such end of 

1 7 session is found, then the data packet is transferred to the IP stack 609 and the process for this 

1 8 packet is ended 610. If, however, a "SYN" is detected, then the inquiry is made as to whether a 

19 connection slot is available 604. Connection slots perform the function of managing the number 

20 of subscribers permitted to have access to the communication network at a given time. If a 

21 connection slot is available, it means that the customer still has client computer access capacity. 

22 If a connection slot is available, a connection slot is allocated 607 and the data packet is 

23 transferred to the IP stack 609 and the process ends. If it is determined that a connection slot is 
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1 not available, then the data packet is dropped or discarded 606 and the process for this packet 

2 ends 610. 

3 Figure 7 depicts a top level flow chart showing the primary steps of the preferred 

4 embodiment of the transmission of i nt ernet lntcrnet protocol datagrams (or packets) method steps 

5 of the invention. Packets that are received from the IP stack are stored on the NewQ 701 . Next 

6 the packet is removed from the NewQ and tested against the-each and every packet on the TxQ 

7 to determine if any TxQ data is redundant or dated and should be replaced 702. If a comparison 

8 of the packet with the TxQ packets finds the updated or "newer" information, then the TxQ 

9 packet data is replaced by the current packet data. This approach is essential to maintaining the 

1 0 fairness of the TxQ packet transfers while ensuring that good data is transmitted thereby 

1 1 improving the transmission efficiency of the system. A test is performed to determine if the 

1 2 packet was included in the TxQ 703. If the packet was not included then the current or NewQ 

1 3 head packet is dropped or discarded 704. Otherwise, if the packet was included, a test is 

14 performed to determine if the NewQ is empty 705. If the NewQ is not empty, the process returns 

1 5 to the test NewQ step where a new NewQ head packet is compared against the TxQ. If, 

16 however, the NewQ is empty, then the process enters a wait state 706 where a trigger^ that is 

1 7 meeting a specified condition, such as new packet on the NewQ or exit command, is required 

1 8 before the process restarts at the testing step 702. 

1 9 Figure 8 depicts a detailed flow chart showing the transfer queue (TxQ) thread processing 

20 steps of the transmission portion of the invention. In the preferred embodiment of the invention 

21 processing the TxQ and processing the NewQ are independent threads of the program which are 

22 capable of running independently on one or more computer processors. In processing the TxQ it 

23 is first determined whether the TxQ is empty 801. If the TxQ is empty, then the process enters a 
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1 wait state 805 where a trigger, such as a polling timer, a transmission complete signal, or an exit 

2 command, is required to resume processing. Note that in the preferred embodiment of the 

3 invention the expected wait time is calculated in this step and the polling time is initiated. If the 

4 TxQ is not empty, a test is made to determine if the head packet of TxQ is too old 802. In the 

5 preferred embodiment of the invention, too old is defined as a packet that has been in the TxQ 

6 for more than sixty (60) seconds. Alternative embodiments could employ any practicable time 

7 period. If the TxQ head packet is too old, then it is discarded 806 and the process returns to the 

8 TxQ empty test 801 . If the TxQ head packet is not too old, then a test is made to determine if the 

9 media, or communication conduit, is capable of transferring another packet of data 803. If the 

1 0 media is capable of transferring another packet, then the packet is written to the transmission 

1 1 device 804, otherwise, the process enters the wait state 805 and waits for a trigger as described 

12 above. 

1 3 Figure 9 depicts a detailed flow chart showing the new queue (NewQ) thread processing 

1 4 steps of the filter queue step of the transmission portion of the invention. The filter queue 

1 5 processing step of the invention, which is the core of step 702, is important in providing the 

1 6 communication efficiency which is one of the key objectives of this invention. A test is made to 

1 7 determine whether the NewQ is empty 901 . If the NewQ is empty then a wait state is entered 

1 8 902 where a trigger, such as new packet available in NewQ, exit or timer count, is required to 

1 9 resume the process. If NewQ is not empty, then the head of NewQ is renamed as ECB 903, a 

20 packet holding variable. The maximum age of the ECB packet is set 904 and a test is performed 

21 to determine if the ECB packet is fragmented 905, that is whether ECB is only a partial packet, 

22 which in the current best mode of the invention is not inspected. If ECB is fragmented, then it is 

23 appended 906 to the TxQ for transmission. If ECB is not fragmented, then a test is performed to 
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1 determine if it is a TCP packet 907. If it is not a TCP packet, then the test is made to determine 

2 if it is a UDP packet 980. If it is not a UDP packet or a TCP packet then it is appended to the 

3 TxQ for transmission 906. If, however, it is a UDP packet, a test is made to determine if ECB is 

4 a duplicate of a DNS request 909. If ECB is not a duplicate of a DNS request, then the packet is 

5 appended to TxQ 906. If ECB is a duplicate of the DNS request, then it is discarded 910 and the 

6 process returns to testing to see if NewQ is empty 901. If it is a TCP packet, then a test is made 

7 to determine if ECB is a "SYN" or beginning of session packet 91 1 . If ECB is a "SYN" packet, 

8 then a test of whether a connection slot is available is made 912. If a connection slot is available 

9 it is allocated 913. If, however, a connection slot is unavailable ECB is discarded 910. If ECB is 

10 not a "SYN" packet then the test is made to determine if ECB is a session abort packet (RST) 

1 1 914. If ECB is found to be a session abort packet TxQ is cleared of all matching packets 915 and 

12 a test is made to determine if ECB will terminate a session 916. If ECB is not a session abort 

13 then the step of clearing all matching packets 915 is skipped. If the ECB is found to terminate a 

14 session, then the connection slot is released 917. A test is then performed to determine if ECB is 

15 void of user data 918. If it contains user data then it is appended to TxQ 906. Otherwise, the 

1 6 End-of-Window-Position (EOWP) is computed 919 and a test is made to determine if ECB's 

17 EOWP is greater than the matched TxQ packets 920, if not ECB is discarded 910, and if so, ECB 

1 8 has its EOWP stored in matched TxQ 921 and then ECB is discarded 910. 

19 Figures 10a-k4- show various screen shots demonstrating the user interface of the 

20 invention. Figure 10a shows the DPC AGENT routine options for user selection as well as the 

21 digital package delivery queue screen. Figure 10b shows a package of data in transit as 

22 displayed on the user screen. Figure 10c shows the main screen of the package delivery 

23 interface. Figure lOd shows package statistics as displayed for user information. Figure lOe 
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1 shows configuration control screens where the user can modify certain modem, package delivery 

2 and provider configuration information. Figure lOf shows the package delivery configuration 

3 editor screens with the information that can be user modified. Figure lOg shows the login script 

4 editor and the provider configuration editor. Figure lOh shows additional provider configuration 

5 editor screens showing the configuration of an outbound protocol case. Figure lOi shows the 



6 dish or antenna pointing adjustments screens. Figure lOj shows the satellite dish signal strength 

7 meter for dish alignment. Figure 10k shows the adapter information screen, here showing site 

8 information including the card hardware serial number, the site identification, the status of keys, 

9 and a list of communities or groups in which the user is participating. 
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